Data communication networks have become of increasing importance over the last decades as evidenced for example by the popularity of the Internet. In order to ensure compatibility between products and to allow an efficient co-operation between the solutions and components provided by different manufacturers and operators, a number of data communication standards have been defined.
In order to provide flexibility and facilitated design and operation for data communication networks, a number of different data communication protocols have been defined which address and focus on different aspects of the data communication. These protocols typically fall into different layers of the Open Systems Interconnection Basic Reference Model (the OSI Reference Model or OSI Model for short) which is a layered, abstract description for communications and computer network protocol design. The OSI model comprises different layers including (from top to bottom), the Application, Presentation, Session, Transport, Network, Data Link, and Physical layers. A layer is a collection of related functions that provides services to the layer above it and receives service from the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that make up the contents of the path.
The best known data communication standard is probably the Internet Protocol (IP) on which the Internet is based. The IP protocol is a layer 3 (network layer) protocol which is used by layer 4 (transport layer) protocols for the communication of data. In many cases, the IP implementation is used in combination with either a Transmission Control Protocol (TCP) or a User Datagram Protocol (UDP) protocol.
In order to continuously improve performance and to provide additional functionality, the defined standards tend to be further developed and new data protocols continue to be defined. Specifically, whereas TCP and UDP are suitable for many applications, they also have some shortcomings. For example, whereas TCP is very suitable for communication of non-real time data, such as file transfers, and UDP is very suitable for transmission of small data messages (datagrams) they tend not to be optimal for supporting applications that require a continuous and possibly real time data stream. Accordingly, a new data protocol known as the Stream Control Transport Protocol (SCTP) has been defined.
SCTP is a reliable, message-oriented transport layer protocol which overcomes many of the drawbacks of TCP and UDP. Indeed, it preserves message boundaries as UDP; it detects lost data, duplicated data and out-of-order data and contains flow and congestion control mechanisms as TCP. Additionally, it features multi-homing (using multiple network interfaces) and multi-streaming (several independent streams in the same connection between two hosts). Thus, a multi-homed host or network element may have a plurality of network interfaces such that it can connect to one or several network(s) through different network interfaces. For example, for an Internet application, a multi-homed host may have two separate Internet connections.
SCTP allows a multi-homed host to establish a connection (also known as an association for SCTP) with another host by providing the other host with the IP addresses (corresponding to its network interfaces) that it wants to use for the connection.
As illustrated in FIG. 1, this is achieved through a four-way handshake between the client and the server upon initialization of the association.
First, the client transmits an INIT message to the server with the INIT message comprising all the network interfaces that the client can be reached on (specifically by including all the corresponding IP addresses).
The server responds by transmitting to the client an INIT-ACK message comprising a cookie (a unique identity of the association) and all the network interfaces on which the server can be reached (again by including all the relevant IP addresses).
The client responds by returning a COOKIE-ECHO message comprising the cookie and the server responds with a COOKIE-ACK message. Following this message, the appropriate resources are allocated and the SCTP association is ready to be used for data transfers between the server and client.
Moreover, SCTP, allows each host to dynamically change the IP addresses used in the association, i.e. to add or remove one (or several) IP address(es). Such a reconfiguration can be achieved by sending an ASCONF message which contains the address(es) the sender wants to add or remove. The remote host responds to receiving an ASCONF message by returning an ASCONF-ACK thereby acknowledging that the ASCONF message has been correctly received and acted on.
However, although SCTP provides a number of advantages, it also has some disadvantages. In particular, a number of problems arise when SCTP is used together with Network Address Translators (NAT). Network address translation is a technique of transceiving network traffic through a router that involves re-writing the source and/or destination addresses. Specifically, a NAT may be used to provide a common (public) IP address for all network elements supported by that NAT. Thus, for any outgoing message of the private network supported by the NAT, the IP address of the originating element is replaced by the IP address of the NAT. Any incoming message will also be addressed to the IP address of the NAT which must then proceed to replace this by the appropriate private IP address of the destination network element. Thus, the NAT must resolve the ambiguity of which network element of the private network is the intended recipient of the received data packet.
For TCP and UDP this ambiguity resolution is typically performed by assigning a unique TCP or UDP port to each connection. Thus, the NAT may store a mapping table which maps the private IP address of each active network element with a unique port number allocated to the connection by the NAT. A destination for an incoming data packet can then be resolved by extracting the corresponding port value for the data packet and using this for a look-up in the mapping table. The corresponding private IP address is then retrieved and used to replace the NAT IP address of the data packet. In order to enable such an approach, the NAT must be able to assign unique port numbers and thus a Port Address Translation (PAT) is also performed by the NAT.
However, such an approach is not suitable for SCTP. Specifically, SCTP uses the source port along with the source IP address to identify the association and therefore it is required that the source port must be the same for all paths between two hosts. Furthermore, as a multi-homed host has a plurality of connections to the network, it will typically be unknown whether such independent network interfaces are supported by the same NAT or by different NATs. Accordingly, if NAT port translation is used, it would be necessary to coordinate the operation of the NATs in order to ensure that the same port would always be allocated to different paths of the same association. Such an approach is typically impractical as it results in increased complexity, increased computational and bandwidth resource requirements etc.
As a specific example, a configuration such as that illustrated in FIG. 2 may be encountered. In this example, two private network elements 201, 203 are supported by the same NAT 205 when communicating with a remote network element 207 via a network 209. In the example, the two network elements 201, 203 may choose the same source port and as the NAT 205 cannot perform port translation, these ports cannot be used to resolve the ambiguity for received data packets (i.e. the port numbers cannot be used to resolve if an incoming data packet addressed to the NAT 205 is intended for the first network element 201 or for the second network element 203).
Another example is shown in FIG. 3 wherein the private network element 201 has two different network interfaces to the NAT 205. As the same port must be used for both network interfaces, this cannot be used by the NAT 205 to resolve the ambiguity for received data packets.
Another example is shown in FIG. 4 wherein the private network element 201 has two different network interfaces but in this example coupled to different NATs 205, 401. In this example, any port translation performed by the NATs 205, 401 would require these to be synchronised to ensure that the same source port was allocated. However, this is impractical as it is generally not known by the individual NAT which other NATs may support a specific network element.
It should also be noted that it is generally not known to the network element 201 which NAT(s) its interface(s) are supported by or indeed whether these are supported by the same or different NATs. Accordingly, any coordination between NATs would require coordination between all possible NATs.
Hence, an improved communication would be advantageous and in particular a system allowing increased flexibility, reduced complexity, reduced computational resource usage, facilitated operation, facilitated and/or improved support for network address translators, facilitated and/or improved support for STCP protocols, and/or improved performance would be advantageous.